Many software applications require the communication of documents and other information among multiple users located at multiple computers, such as collaboration software, portfolio management applications, and workgroup support systems. These types of applications may be deployed upon traditional client-server network architectures, where a central server maintains the documents and other information, or peer-to-peer (P2P) networks. P2P networks have an advantage over client-server architectures in that the peer-to-peer computers or devices provide the resources, such as bandwidth, storage space, and computing power. Thus, as there is more demand on the P2P network by the addition of more peer-to-peer devices, the total capacity of the system also increases, unlike traditional client-server networks where adding more clients can result in slower processing for all users. P2P networks also provide redundancy by replicating data over multiple peer-to-peer devices, and thus there is no single point of failure in the system, as may exist in traditional client-server architectures.
However, as the underlying network architecture of a P2P network gets more complicated, there arises a need for some services to become centralized, resulting in a hybrid P2P system. For instance, a P2P network in which the peer-to-peer devices are located on diverse networks and separated by firewalls or proxies may require a central server that knows about the devices participating in the P2P network and routes information between the remote peer-to-peer devices. An example of this type of hybrid P2P network is the MICROSOFT OFFICE GROOVE collaboration software from MICROSOFT CORPORATION of Redmond, Wash. In a GROOVE hybrid P2P implementation, individual peer-to-peer devices may inform a central relay server of changes to resources owned by that device, and the relay server may forward the changes to other devices participating in the P2P network. This allows for the efficient distribution of changes to other peer-to-peer devices that may not be directly connected to the central network or may connect at a later time.
With potentially thousands of devices participating in such a hybrid P2P network, the processing load on a relay server can become very high, potentially causing server instability that can lead to a crash or the dropping of requests from peer-to-peer devices. It is essential, therefore, that the relay server implements a flow control mechanism to prevent this instability and to ensure that device messages continue to be forwarded. However, traditional control mechanisms are generally limited to static hysteresis mechanisms, wherein simple flow control is imposed on all devices when resource utilization, such as the number of connections, reaches a threshold value or “high water mark”, and removed again when utilization drops below an associated “low water mark”. These mechanisms often do not take into account the true, current performance and processing load on the server, which may vary depending upon the size and number of requests being made to the relay server as well as processing resources required by other applications executing on the server computer at the same time.
It is with respect to these considerations and others that the disclosure made herein is presented.